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CENTRALIZED MANAGEMENT SYSTEM 
FOR PROGRAMMABLE MEDICAL DEVICES 
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Field of the Invention 



The present invention relates to the field of programmable medical devices. More 
particularly, this invention relates to a management system for medical devices that have 
at least one parameter that is programmable based upon at least one characteristic of a 
patient. 



Background of the Invention 

Implantable medical devices are commonly used for treating various medical 
conditions, many of v^hich relate to the heart. For example, cardiac rhythm management 
(CRM) implantable devices are often implanted in patients to deliver therapy to the heart. 



Pacers deliver timed sequences of low energy electrical stimuli, called "pace pulses", to the 
heart via an intra vascular leadwire or catheter (referred to as a "lead") having one or more 
electrodes disposed in or about the heart. The pace pulses initiate heart contractions in a 
process called "capturing" the heart. By properly timing the delivery of the pace pulses, a 

20 heart with an irregular cardiac rhythm (i.e., a cardiac arrhythmia) can be induced to contract 
with a proper rhythm, thereby improving its efficiency as a pump. Pacers are often used 
to treat patients with bradyarrhythmias (i.e., hearts that beat too slowly, or beat irregularly). 

CRM implantable devices also include cardioverters or defibrillators that are 
capable of delivering higher energy electrical stimuli to the heart. Defibrillators are often 

25 used to treat patients with tachyarrhythmias (i.e., hearts that beat too quickly). Such too- 
fast heart rhythms can cause the heart to pump inefficiently since the heart is not allowed 
sufficient time to fill with blood before contracting to expel the blood. A defibrillator is 
capable of delivering a high energy electrical stimulus that is sometimes referred to as a 
"defibrillation countershock". The countershock interrupts the tachyarrhythmia to allow 
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CRM implantable devices include, for example, cardiac pacemakers or "pacers". 
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the heart to re-establish a normal rhythm for efficiently pumping the blood. Still other 
types of CRM implantable devices include, for example, pacer/defibrillators that combine 
the functions of both pacers and defibrillators, drug delivery devices, or any other 
implantable medical devices that are used for diagnosing and/or treating cardiac 
5 arrhythmias. 

CRM implantable devices are often capable of delivering therapy to the heart of a 
patient in a manner that depends on one or more parameters that can be set or adjusted by 
the patient's physician. For example, a pacer may have programmable parameters such as 
atrioventricular (AV) delay (i.e., the length of time between an atrial sensed or atrial paced 
10 event and the delivery of a ventricular output pulse), an LV offset (i.e., the length of time 
between a sensed or paced event in a first ventricle and the delivery of an output pulse to 
j"^ a second ventricle), a target heart rate, whether or not to tum on rate smoothing, smoothing 

□ percentage for increasing rate, smoothing percentage for decreasing rate, etc. The 

O 

fg programmable parameters depend on the particular CRM implantable device, and are 

1 5 typically intended to be programmed based upon the physician' s evaluation of the patient. 

The primary clinical tool that allows a physician to set or update programmable 



5 



parameters of a CRM implantable device is a medical device programmer. Such medical 
^ device programmers often use inductive coils to provide bidirectional telemetry between 

Nt the programmer and the implantable device. By using such a programmer, a physician can 

P 

1^ 20 receive and view stored cardiac and system data from the implantable device, and can send 
programming instructions back down to the implantable device. Thus, programmers allow 
physicians to set or adjust the progranmiable parameters of implantable medical devices. 

As additional therapeutic features are introduced into CRM implantable devices, 
programming such devices to provide optimal therapy for a particular patient has become 
25 an increasingly complicated task for medical practitioners. For example, many medical 
practitioners who may implant only a few devices per year do not have the time nor the 
resources that would be needed to optimally program such devices. Even practitioners 
more familiar with such devices, such as physicians who perform perhaps 50 implants per 
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year and who may know how to create custom profiles for particular classes of patients for 
particular devices, typically do not have the time nor the resources to stay current with each 
new development in the field. Such problems are likely to worsen as the number of 
different types of implantable devices increases, and as each type of implantable device 
5 becomes more complex. As a result of such problems, many if not most practitioners use 
only the factory-set, defauh parameters of CRM implantable devices, while other medical 
practitioners may adjust only a subset of the parameters from the factory-set parameters. 
While using default parameters may provide adequate therapy for a generalized class of 
patients, the use of such parameters often does not provide optimal therapy for a particular 
10 patient. 

Thus, even though medical device progranmiers give medical practitioners the 
capability to set or update the programmable parameters of CRM implantable devices, the 
medical practitioners often lack the resources and the knowledge that would be needed to 
optimally program such devices to provide optimal therapy for particular patients. This 
15 problem is likely to worsen as new types of CRM implantable devices are developed, and 
as new and additional features are added to new and existing CRM implantable devices. 
As a result, the therapeutic benefits of such devices may not reach their fiiU potential. 

Therefore, it would be advantageous to provide an improved system and method for 
programming CRM implantable medical devices that solves these and other problems. 

20 

Summary of the Invention 

In accordance with one aspect of the present invention, a centralized management 
system for medical devices includes a network, a central server coupled to the network, and 
a medical device programmer also coupled to the network. The central server includes at 
25 least one prescription system for prescribing at least one programmable parameter of a 
medical device based upon at least one characteristic of a patient. The medical device 
programmer communicates at least one characteristic of a patient to the central server via 
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the network, receives at least one programmable parameter from the central server via the 
network, and programs the medical device using the at least one progranraiable parameter. 

In accordance with another aspect of the present invention, a central server for use 
in a centralized management system for medical devices includes a network interface for 
5 communicating with a medical device programmer over a network, and at least one 
prescription system coupled to the network interface. Each prescription system is able to 
receive at least one characteristic of a patient from the medical device progranmier via the 
network, to prescribe at least one programmable parameter of a medical device based upon 
the at least one characteristic of the patient, and to transmit the at least one prescribed 
1 0 programmable parameter to the medical device programmer via the network. 

In accordance with another aspect of the invention, a medical device programmer 
^ for use in a centralized management system for medical devices includes a network 

D interface for communicating with a central server over a network, a medical device 

P 

^ interface for conmiunicating with a medical device, and a processor coupled to the network 

I 3 3 

p 15 interface and the medical device interface. The processor communicates at least one 
^ characteristic of a patient to the central server via the network, receives at least one 

a 

^ prescribed parameter of the medical device from the central server via the network, and 

p programs the medical device using the at least one prescribed parameter via the medical 

'^•J device interface. 

□ 

20 In accordance with another aspect of the present invention, a method of 

programming a programmable medical device includes determining at least one 
characteristic of a patient at a medical device programmer, conmiunicating the at least one 
characteristic to a central server, determining at least one programmable parameter for a 
medical device based upon the at least one characteristic using a prescription system hosted 

25 by the central server, communicating the at least one programmable parameter to the 
medical device programmer, and programming the medical device using the at least one 
programmable parameter. 
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These and various other features as well as advantages which characterize the 
present invention will be apparent to a person of ordinary skill in the art upon reading the 
following detailed description and reviewing the associated drawings. 

5 Brief Description of the Drawings 

FIG. 1 is a block diagram of a centralized management system for implantable 
medical devices that have at least one parameter that is programmable based upon at least 
one characteristic of a patient, in accordance with one embodiment of the invention; 

FIG. 2 is a block diagram including one implantable medical device from FIG. 1 ; 
10 FIG. 3 is a block diagram including one medical device programmer from FIG. 1 ; 

FIG. 4 is a block diagram including the central server from FIG. 1; 
FIG. 5 is a flow chart illustrating prescription system selection logic of the 
centralized management system of FIG. 1, which allows a user to select a customized 
prescription system defined by that user, or to select one of a plurality of expert prescription 
^ 15 systems; 

FIG. 6 is a block diagram representing a custom prescription system defined by a 

s 

U> user for determining a set of parameters for use in programming an implantable medical 

U 

device; 

M FIG. 7 is a flow chart illustrating exemplary logic for programming an implantable 

20 medical device using the custom prescription system of FIG. 6; 

FIG. 8 is a block diagram representing an expert prescription system defined by an 
expert for determining a set of parameters for use in programming an implantable medical 
device; and 

FIG. 9 is a flow chart illustrating exemplary logic for programming an implantable 
25 medical device using the expert prescription system of FIG. 8. 



□ 
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Description of the Preferred Embodiments 

In the following detailed description, reference is made to the accompanying 
drawings, which form a part hereof, and in which is shown by way of illustration specific 
embodiments in which the invention may be practiced. In the drawings, like numerals 
5 refer to like components throughout the views. These embodiments are described in 
sufficient detail to enable those skilled in the art to practice the invention, and it is to be 
understood that the embodiments may be combined, or that other embodiments may be 
utilized and that structural, logical and electrical changes may be made without departing 
from the spirit and scope of the invention. The following description is, therefore, not to 
10 be taken in a limiting sense, and the scope of the invention is defined by the appended 
claims and their equivalents. 
^ Referring to FIG. 1 , a centralized management system 1 00 for implantable medical 

□ devices is shown, in accordance with one embodiment of the present invention. System 

O 

^ 100 includes a network 102, a central server 104 coupled to network 102, one or more 

^ 1 5 medical device programmers 1 06 coupled to network 1 02, and one or more expert clients 

^ 1 08 also coupled to network 1 02 . In system 1 00, each medical device programmer 1 06 and 

1=1= each expert client 108 is capable of communicating with central server 104 via network 

Q 102. In another embodiment of the invention, system 100 does not include any of the 

y expert clients. 

O 

M= 20 In one embodiment, network 102 is a wide area network (WAN) that allows for 

bidirectional communications to occur over a wide geographic area. For example, network 
102 may include point-to-point unswitched private communication lines such as Tl or T3 
lines, or switched lines like those of the public switched telephone network (PSTN), ISDN 
lines, etc. For another example, network 102 includes the Internet. Using a WAN 
25 eliminates or reduces any geographic restrictions placed on the locations of central server 
104, medical device programmer(s) 106, and expert client(s) 108, and any two of these 
components can be physically located close to one another, far fi^om one another, or any 
distance in between. In various embodiments, the conununications between central server 
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104, progranuner(s) 106 and expert client(s) 108 takes place over an electrical, optical, 
radio-frequency (RF), or wireless communication medium, or a combination of such 
conmiunication mediums. 

In another embodiment, network 1 02 is a local area network (LAN) that allows for 
5 conunimications to occur over a local geographic area, such as within a building or 
complex. For example, network 102 may include an Ethernet or token ring network in a 
hospital or hospital complex. In yet another embodiment, network 102 is a metropolitan 
area network (MAN) generally covering a metropolitan geographic area such as a city, town 
or county. 

1 0 Central server 1 04 hosts at least one prescription system for prescribing at least one 

programmable parameter of a medical device based on at least one characteristic of a 
^ patient. The at least one patient characteristic is received by central server 104 from any 

O of the medical device programmers 106 via network 102, and the at least one prescribed 

D 

^ programmable parameter is then transmitted back to that programmer via network 1 02 for 

W 

jjl 15 use m programmmg a medical device that will provide therapy for the patient. Thus, by 
executing a prescription system, central server 104 is capable of prescribing one or more 
programmable parameters for a medical device based upon at least one characteristic of a 
p patient. In one embodiment, central server 104 includes a computer system and software 

^ that are dedicated to hosting the at least one prescription system. In another embodiment, 

20 central server 104 includes software that executes on a computer system that runs other 
applications. Central server 1 04 may thus include a combination of hardware and software, 
or software only. Central server 104, and its operation in system 100, is described fiirther 
below. 

Each medical device progranmier 106 communicates at least one characteristic of 
25 a patient to central server 104 via network 102, and receives at least one prescribed 
programmable parameter of a medical device from central server 104 via network 102. 
Each medical device programmer 106 receives the at least one characteristic from any or 
all of a number of different sources (described below), and uses the at least one prescribed 
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parameter to program an implantable medical device 110 coupled to the progranmier 106. 
Each medical device programmer 1 06, and its operation in system 1 00, is described further 
below. 

As illustrated in FIG. 1, each medical device programmer 106 allows a medical 
5 practitioner (e.g., a physician, nurse, technician, etc.) to program an implantable medical 
device 1 10. In one embodiment, each implantable medical device 1 10 is a cardiac rhythm 
management (CRM) implantable device such as a pacer, a cardioverter or defibrillator, a 
pacer/defibrillator, or another type of CRM implantable device such as a drug delivery or 
another type of implantable medical device used to diagnose or treat cardiac arrhythmias. 
10 In another embodiment, any or all of medical device programmers 1 06 is coupled 

to, and is capable of programming, another type of implantable medical device that is 
Q programmed according to the individual characteristics of the patient, but is not used to 

O diagnose or treat cardiac arrhythmias. For example, any or all of programmers 1 06 may be 

O 

^ coupled to, and be capable of programming, an implantable drug delivery device that is not 

W 

jjl 15 used for CRM purposes. In yet another embodiment, any or all of programmers 106 is 
coupled to, and is capable of programming, a non-implantable medical device that is 
progranmied according to the individual characteristics of the patient. For example, any 
p or all of programmers 1 06 may be coupled to, and be capable of programming, an extemal 

^ pacer that is disposed on the chest of a patient in order to deliver therapeutic pace pulses. 

20 In one embodiment, centralized management system 1 00 is capable of programming 

just one type of medical device. For example, system 100 could be capable of 
programming only a particular type of pacer. In another embodiment, system 100 can 
program more than one type of medical device. In this embodiment, any of multiple types 
of medical devices can be programmed using any of medical device programmers 1 06. For 
25 example, a practitioner equipped with a programmer 106 can use central server 104 to 
prescribe a first set of programming parameters to program a pacer for a first patient, and 
a second set of programming parameters to program a defibrillator (or another type of 
pacer) for a second patient. In one embodiment, programmer 106 identifies the type of 
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medical device being programmed (e.g., from a user input), and transmits that information 
to the central server. 

Note that a CRM or non-CRM implantable medical device is programmable by an 
appropriate medical device programmer 106 regardless of whether or not that device has 
5 actually been implanted into the body of a patient. For example, an implantable pacer can 
be programmed before that pacer is implanted into the body of a patient, and can also be 
programmed when that pacer is outside the body (e.g., before being implanted). Thus, an 
"implantable" medical device refers to a medical device that is capable of being implanted 
into the body of a patient, regardless of whether or not that device is actually implanted. 
1 0 In the embodiment of FIG. 1 , system 1 00 includes one or more expert clients 108. 

Each expert client 108 is used by an expert to define and/or update an expert prescription 
^ system that is hosted by central server 104, via network 102. Each expert prescription 

D system is configured by the respective expert to prescribe one or more programmable 

n 

^ parameters for a medical device (or different types of medical devices) based on at least one 

15 characteristic of a patient, in accordance with the expert's knowledge and skills. In one 
embodiment, each expert client 108 includes a workstation, personal computer or other 
computing device that is progranmied to perform the functions described herein. In another 
embodiment, one or more expert clients 1 08 are hosted by the computer system that serves 
2 as central server 1 04. Each expert client 1 08, and its operation, is described further below. 

20 In another embodiment, system 1 00 does not include any expert clients 1 08 . In such 

an embodiment, information representing each expert's knowledge and skills may be 
entered directly into central server 104 to define or update the prescription system of that 
expert. For example, an expert could develop an expert system offline, and that expert 
system could be loaded onto central server 104 using a magnetic or optical disc, or other 
25 medium for data exchange. Alternatively, if central server 1 04 does not include any expert 
prescription systems, information representing an expert's knowledge and skills would not 
be needed. 
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Thus, FIG. 1 illustrates one embodiment of a centralized management system 100 
for implantable medical devices 1 10, which includes a network 102, a central server 104, 
one or more medical device programmers 1 06, and one or more expert clients 1 08. Central 
server 104 includes at least one prescription system for prescribing at least one 
5 programmable parameter of a medical device based on at least one characteristic of a 
patient. Each medical device programmer 106 is configured to transmit at least one 
characteristic of a patient to central server 104 via network 102, to receive at least one 
programmable parameter from central server 104 via network 102, and to program an 
implantable medical device 110 using the at least one programmable parameter. The 
10 components of centralized management system 100 are now described in further detail. 
While the following discussion often refers to devices 1 10 as being implantable medical 
devices, devices 110 can be any type of medical device that is programmable based on at 
least one characteristic of a patient. 

Referring to FIG. 2, a block diagram 200 shows an exemplary implantable medical 
15 device 110, in accordance with one embodiment of system 100. Implantable medical 
^ device 1 1 0 is configured to communicate with one of medical device programmers 1 06 via 

a communications link 202. In one embodiment, link 202 uses radio-frequency (RF) 
p signals that can pass through the body of a patient when device 1 10 is implanted. In 

^ another embodiment, link 1 06 uses optical signals than can pass through the patient' s body 

20 when device 1 1 0 is implanted. Thus, programmer 1 06 and implantable medical device 1 1 0 
can communicate regardless of whether or not device 1 10 is implanted in a patient. These 
communications support monitoring, diagnostic and programming fimctions of device 110. 

In this embodiment, implantable medical device 1 10 is a pacer that is operatively 
coupled to a patient's heart 204 by a pacing lead 206. The components of implantable 
25 medical device 1 1 0 include, for example, an atrial sense amplifier 208, a ventricular sense 
amplifier 210, an atrial stimulating circuit 212, a ventricular stimulating circuit 214, a 
controller 216, a memory 218, and an input/output (I/O) interface 220. Device 1 10 may 
also include other components that are known to people of ordinary skill in the art, such as 



W 

m 
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an accelerometer (not shown) for measuring patient activity. The components of 
implantable medical device 1 1 0 are housed within an implantable housing (indicated by the 
broken lined box in FIG. 1.) that is implanted in the patient's chest cavity (e.g., in the 
pectoral region). 

5 Atrial sense amplifier 208, ventricular sense amplifier 2 1 0, atrial stimulating circuit 

212 and ventricular stimulating circuit 214 are operatively coupled to pacing lead 206 via 
a pair of conductors 222. Pacing lead 206 includes an atrial sensing electrode 224 and atrial 
stimulating electrode 226 adapted to be disposed in the right atrial chamber of heart 204, 
and a ventricular sensing electrode 228 and ventricular stimulating electrode 230 adapted 
10 to be disposed in the right ventricular chamber of heart 204. Sensed atrial and ventricular 
electrical signals generated by sensing electrodes 224 and 228 are applied to atrial and 
^ ventricular sense amplifiers 208 and 210, respectively. Atrial and ventricular stimulating 

O signals generated by atrial and ventricular stimulating circuits 2 1 2 and 2 1 4 are applied to 

O 

^ atrial and ventricular stimulating electrodes 226 and 230, respectively. Atrial sense 

^ 1 5 amplifier 208, ventricular sense amplifier 2 1 0, atrial stimulating circuit 2 1 2, and ventricular 

«P stimulating circuit 2 1 4, are also each operatively coupled to controller 2 1 6. 

s 

^ Controller 216 includes a micro-controller or microprocessor which is configured 

p to execute a program stored in a read-only memory (ROM) portion of memory 218, and to 

read and write data to and from a random access memory (RAM) portion of memory 218. 

P 

^ 20 In one embodiment, memory 2 1 8 also includes an electrically-erasable programmable read 
only memory (EEPROM) portion that is used by the micro-controller or microprocessor for 
storing and retrieving one or more progranmiable parameters for the medical device. By 
executing the program stored in memory 218, controller 216 is configured to process the 
atrial and ventricular electrical signals from atrial and ventricular sense amplifiers 208 and 
25 210, and to provide control signals to atrial and ventricular stimulating circuits 212 and 
214. In response, stimulating circuits 212 and 214 provide stimulating pulses to heart 204 
via atrial and ventricular stimulating electrodes 226 and 230 at appropriate times. In other 
embodiments, controller 2 1 6 may include other types of control logic elements or circuitry. 
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Implantable medical device 1 10 is capable of delivering therapy to the patient in a 
manner that depends on one or more parameters than can be programmed by the patient's 
physician or other medical practitioner using medical device programmer 106. For 
example, in one embodiment, device 1 10 is a pacer capable of delivering therapy to heart 
5 204 that has one or more programmable parameters such as an atrioventricular (AV) delay, 
an LV offset, a target heart rate, whether or not to tum on rate smoothing, smoothing 
percentage for increasing rate, smoothing percentage for decreasing rate, etc. When any 
of these or other progranmiable parameters is downloaded to implantable medical device 
110 from medical device programmer 106, controller 216 stores the received parameter 
10 value(s) in memory 218. Then, during operation of device 1 10, controller 216 reads the 
progranmiable parameters from memory 2 1 8, and uses those values to adjust the operations 
of device 110. 

The implantable medical device shown in FIG. 2 is a dual-chamber pacemaker, 
since pacemaking functions are provided to both atrial and ventricular chambers of the 

15 heart. In another embodiment, one or more of the implantable medical devices is another 
type of pacemaker, such as a single-chamber pacemaker that senses electrical signals and 
provides stimulating pulses to a single chamber of the heart. In another embodiment, one 
or more of the implantable medical devices is another type of CRM device, such as a 
defibrillator, a pacer/defibrillator, a drug delivery device or another implantable medical 

20 device used for diagnosing or treating cardiac arrhythmias. In another embodiment, one 
or more of the implantable medical devices is a non-CRM implantable medical device such 
as an implantable drug delivery device not used for CRM purposes. In yet another 
embodiment, any or all of the medical devices programmed by programmer(s) 1 06 is a non- 
implantable medical device that is progranuned according to the individual characteristics 

25 of the patient. In each case, the medical device includes a memory such as memory 2 1 8 in 
which one or more programmable parameters downloaded from programmer 106 is stored 
for later use. 
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Referring to FIG. 3, a block diagram 300 shows one of medical device programmers 
106, in accordance with one embodiment of system 100. Programmer 106 is configured 
to communicate with one of implantable medical devices 1 1 0 via communications link 202. 
In one embodiment, programmer 106 is electrically coupled to a wand 302 that can be 
5 moved into close proximity with a patient 3 04 to allow RF, optical or a combination of RF 
and optical signals to pass between wand 302 and a medical device 110 implanted in the 
patient. Programmer 106 is also configured to communicate with central server 104 via 
network 102. 

In this embodiment, medical device programmer 106 includes a processor 306 and 
10 a memory 308 coupled to processor 306 via a communications bus 310. By executing a 
program stored in memory 308, processor 306 is configured to perform the functions 

Ufa 

g described herein. Programmer 106 also includes an implantable device interface 312, a 

O network interface 3 1 4, a user input device interface 3 1 6, and a user output device interface 

P 

M 318, each of which is coupled to processor 306 via bus 3 1 0. Implantable device interface 

W 

jjl 15 3 1 2 is coupled to wand 302 to allow processor 306 to communicate with medical device 
110. Network interface 314 is coupled to network 102 to allow processor 306 to 
\^ communicate with central server 1 04. User input device interface 3 1 6 is coupled to one or 

□ more user input devices 320 to allow processor 306 to receive inputs from a user (e.g., 

^ medical practitioner). User input devices 320 include, for example, one or more of a 

20 keyboard, a keypad, a mouse, a touchscreen, a microphone and voice-recognition circuit, 
a light pen, etc. User output device interface 318 is coupled to one or more user output 
devices 322 to allow processor 306 to provide outputs to the user. User output devices 322 
include, for example, a display, a touchscreen, a printer, a strip-chart recorder, a speaker, 
etc. In FIG. 3, user input device(s) 320 and user output device(s) 322 are shown as part of 
25 programmer 1 06. Alternatively, any or all of the user input devices and user output devices 
may be external to programmer 106. 

Wand 302, and implantable device interface 3 1 2, allow programmer 1 06 to transmit 
one or more progranmiable parameters to implantable medical device 1 1 0. In addition, in 



Attorney Docket No. 279.373US1 



Client Ref No. 00-204 



one embodiment, wand 302 and interface 312 allow programmer 106 to receive signals 
from implantable medical device 110, such as signals representing one or more 
characteristics of the patient. For example, these signals could include, or be derived from, 
signals sensed by sensing electrodes 224 and 228 (FIG. 2), or by some other sensor 
5 implanted in the patient. 

User input device(s) 320 allow users (e.g., medical practitioners) to input data 
and/or control operations of programmer 106. For example, where programmer 106 can 
program more than one type of medical device, a user can actuate an input device 320 to 
generate an input signal specifying the type of medical device being programmed. For 

10 another example, where central server 104 hosts both expert and custom prescription 
systems, a user can actuate an input device 320 to select between the expert and custom 
prescription systems. For another example, where central server 104 hosts multiple expert 
prescription systems, a user can actuate an input device 320 to generate an input signal 
selecting one of the expert prescription systems. For yet another example, where a user can 

15 input one or more patient characteristics, the user can actuate an input device 320 to 
generate input signals representmg at least one characteristic of patient 304. In each case, 
data representing the input signals is communicated by programmer 106 to central server 
104 via network 102 for use by central server 104 in prescribing one or more parameters 
for the medical device being programmed. 

20 In one embodiment, programmer 106 also includes a patient monitoring system 

interface 324 that is also coupled to processor 306 via bus 310. Interface 324 is coupled 
to a patient monitoring system 326 to receive signals that represent at least one 
characteristic of patient 304. These signals are thus available to processor 306 via bus 3 1 0, 
and are communicated by processor 306 to central server 104 via network 102 for use by 

25 central server 104 in prescribing one or more parameters for the medical device being 
programmed. Patient monitoring system 326 can include, for example, a surface 
electrocardiograph (ECG) system having one or more sensing electrodes disposed on the 
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patient's chest, or some other type of system for sensing or monitoring one or more 
characteristics of the patient 304. 

In one embodiment, programmer 106 includes an interface 328 to a patient records 
computer system 330 that is also coupled to processor 306 via bus 310. Patient records 
5 computer system 330 stores patient records, such as the medical record of patient 304. 
Thus, processor 306 may access the medical records of patient 304, and communicate data 
from this medical record to central server 1 04 via network 1 02 for use by central server 1 04 
in prescribing one or more parameters for the medical device being programmed. This 
data may include, for example, general patient data such as gender, age, etc. of patient 304, 

1 0 or more specific patient data such as the results of a particular diagnostic test. Interface 328 
may, for example, include a local area network interface 328 for accessing patient records 
computer system 330 over a local area network. By providing access to the patient's 
record, the amount of data that needs to be manually input by the medical practitioner may 
be decreased. In one embodiment, the medical practitioner enters information identifying 

15 the patient into programmer 106 which is used in retrieving the medical record for that 
patient. 

Thus, there are a number of ways by which programmer 1 06 can gather one or more 
characteristics of patient 304 for transmittal to central server 1 04. The ways include having 
a medical practitioner manually enter data using input device(s) 320, receiving data from 
20 implantable medical device 110, receiving data from patient monitoring system 3 26, and/or 
receiving data from patient records computer system 330. In any event, the one or more 
characteristics of patient 304 are communicated to central server 104 via network 102 for 
use in prescribing one or more parameters for programming the implantable medical 
device. 

25 In one embodiment, medical device programmer 106 is similar to the ZOOM™ 

programmer available from the Guidant Corporation of Minnesota, except for the following 
differences: the addition of interface 314 to central server 104; the (optional) addition of 
interface 324 to patient monitoring system 326; the (optional) addition of interface 328 to 
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patient records computer system 3 30; and the configuration (e.g., programming) of medical 
device programmer 106 to perform the functions described in the present application. 

Referring to FIG. 4, a block diagram 400 shows central server 104, in accordance 
with one embodiment of system 100. Central server 104 is configured to communicate 
5 with any of medical device programmers 106 or expert clients 108 via network 102. 
Central server 1 04 is also configured to conununicate with a system administration terminal 
402. 

In this embodiment, central server 104 includes a processor 404 along v^th a 
memory 406, a network interface 408, and a terminal interface 410, each coupled to 

1 0 processor 404. By executing a program stored in memory 406, processor 404 is configured 
to perform the fimctions described herein. Network interface 408 is coupled to network 
1 02 to allow processor 404 to communicate with any of progranmiers 1 06 or expert clients 
108, Terminal interface 410 is coupled to terminal 402 to allow processor 404 to 
communicate with system administrator terminal 402. In one embodiment, processor 404 

15 is coupled to the other components 406, 408 and 410 of central server 104 via a 
conmiunications bus (not shown). 

Using network interface 408, processor 404 receives one or more characteristics of 
a patient from one of the medical device programmers 106 in centralized management 
system 100, and transmits at least one prescribed parameter back to that programmer 106 

20 for use in programming an implantable medical device 1 10 coupled to that programmer 
106. In various embodiments, network interface 408 is also involved in communicating 
other data between central server 104 and the progranmier 106, such as signals input by a 
user to specify the type of medical device being programmed, to select whether to use an 
expert or custom prescription system, or to select which of multiple expert prescription 

25 systems to use. In one embodiment, using network interface 408, processor 404 also 
receives data fi-om one or more expert clients 1 08 which is used for creating or updating 
one or more expert prescription systems stored in memory 406, in a manner that is fiirther 
described below. 
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In the embodiment shown in FIG. 4, central server 104 hosts a number of 
prescription systems, including a number of expert prescription systems 412. Each expert 
prescription system 412 comprises an object, including code and data, executed by 
processor 404 when that expert prescription system is selected. Each expert prescription 
5 system 412 is defined by an expert to prescribe at least one parameter of an implantable 
medical device based on at least one characteristic of a patient. For example, the expert 
prescription systems 412 shown in FIG. 4 were defined by an Expert A, an Expert B, and 
an Expert C. Although three expert prescription systems are shown, central server 1 04 may 
include fewer than or more than three expert prescription systems, each defined by an 
1 0 expert. As described below, a medical practitioner using a programmer 1 06 can select one 
expert prescription system 412 to use in prescribing a set of programmable parameters for 
^ the implantable medical device. By selecting such an expert prescription system, the 

g medical practitioner is able to benefit fi-om the knowledge and skills of the expert who 

03 defined that expert prescription system. 

X s 

mis In the embodiment of FIG. 4, each expert prescription system 4 1 2 is defined by a 

different expert. This embodiment accounts for the fact that the practice of medicine is not 



standard. In particular. Physician A may provide different advice than Physician B on the 
p same facts, even though both physicians are experts, and the advice of each physician is 

^ sound. In one embodiment, information about the experts is stored by central server 1 04, 

20 and is downloaded from central server 1 04 to programmer 1 06 for presentation to the user 
to aid the user in selecting which expert to select. This information may include the 
expert's name and/or biographical information about the expert, such as information about 
the expert's education and/or experience. For example, a user could be presented with the 
choice of selecting between a first expert system that was defined by a Dr. Smith of the 
25 Mayo Clinic, or a second expert system that was defined by a Dr. Jones of the Boston 
Children's Hospital. 

In another embodiment, any or all of the expert prescription systems is defined by 
a group of experts. For example, the manufacturer of a particular implantable medical 
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device could define an expert prescription system for that device that combines the 
knowledge and skills of a team of experts who were involved in the development of that 
device. For another example, a team of experts could be assigned the task of working 
together to define an expert prescription system for a particular medical device. In each 
5 case, a medical practitioner using system 100 could then benefit firom the combined 
knowledge and skills of the experts. 

In the embodiment shown in FIG. 4, central server 104 also hosts a number of 
custom prescription systems 414. Each custom prescription system 414 comprises an 
object, including code and data, executed by processor 404 when that custom system is 
1 0 selected. Each custom prescription system 4 1 4 is defined by a user to prescribe at least one 
parameter of a medical device based on at least one characteristic of a patient. However, 
Q imlike expert prescription systems 412, each custom prescription system 414 can only be 

O selected by the user who defined that system 414. For example, FIG. 4 shows two custom 

O 

^ prescription systems 4 1 4 that were defined by a User A and a User B. In this case, User A 

15 can only access the custom prescription system defined by User A, and cannot access the 
custom prescription system defined by User B. Conversely, User B can only access the 
custom prescription system defined by User B, and cannot access the custom prescription 
p system defined by User A. A User C cannot access the custom prescription system defined 

p by either User A or User B. To provide this access control, each user is required to logon 

M' 20 to system 1 00 using a login identification. The custom prescription aspects of system 1 00 
are intended for medical practitioners who are familiar enough with implantable medical 
devices to create custom profiles for particular classes of patients for particular devices, but 
are not experts in the field who are in a position to give programming advice to other 
medical practitioners. 

25 As described above, each "user" may be a single medical practitioner. In another 

embodiment, each "user" may include a group of medical practitioners who are associated 
with each other. For example, a single "user" may include two physicians who work 
closely together, and who use centralized management system 100 to share progranmiing 



s 
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data. In this embodiment, the association of the practitioners is used to insure the quality 
of the custom prescription system. Practitioners not part of the association, however, are 
not allowed to use the custom prescription system since that system was not created by an 
expert. 

5 Thus, in one embodiment, central server 104 includes or hosts a number of 

prescription systems, including one or more expert prescription systems and one or more 
custom prescription systems, that are selectable by a user to prescribe one or more 
programming parameters of a medical device based on at least one characteristic of a 
patient. The manner in which this selection occurs, in one embodiment, is illustrated in 
10 FIG, 5. 

Referring to FIG. 5, a flow chart 500 illustrates selection logic used by centralized 
^ management system 1 00 to allow a user of a medical device programmer 1 06 to select one 

Q of a plurality of prescription systems hosted by central server 1 04. At 502, a user logon to 

^ system 100 is performed. For example, a user may input his or her user name to 

HI 15 programmer 1 06 using a user input device 320. For additional security, the user may also 
^ be requested to input a password. Programmer 106 communicates the user name and 

M' password to central server 104, which determines whether the user is authorized. If so, 

p central server 104 sends a message to programmer 106 indicating that the logon was 

^ successful, and programmer 106 continues the selection logic. If not, central server 104 

N= 20 sends a message to programmer 1 06 indicating that the user is not authorized to use system 
100. In one embodiment, system 100 presents a message on a user output device 322 to 
invite the unauthorized user to contact the system administrator to gain access to system 
100, if that user is interested in doing so. The system administrator can then use terminal 
402 to register the user as an authorized user. Alternatively, the unauthorized user can be 
25 allowed to register online to use system 1 00. 

At 504, system 1 00 determines whether a custom prescription system is defined for 
the user. For example, if the user is authorized, central server 1 04 determines whether any 
of the custom prescription systems 414 stored in memory 406 is defined for that user, and 
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communicates the result to programmer 106. If a custom prescription system 414 is 

defined for the user, the user is queried at 506 to determine whether to use that custom 

prescription system, or an expert prescription system. For example, the query is presented 

to the user using a user output device 322, and the user responds using a user input device 

5 320. Note that the user is not given the choice of using any of the other custom prescription 

systems since these other systems were not defined by the user, or by an expert. At 508, 

system 100 determines whether the user wants to use the custom prescription system. If 

so, then at 5 1 0, system 1 00 selects the custom prescription system defined for that user to 

prescribe one or more parameters for an implantable medical device 1 1 0 being programmed 

10 by that user. 

At 512, if the user wants to use an expert prescription system, or if a custom 

prescription system is not defined for the user, then system 100 queries the user to 

determine which expert to use. For example, central server 104 determines which expert 

prescription systems 412 are defined for the implantable medical device 110 being 
jjj 

m 15 programmed, and communicates information about the respective experts to programmer 
^ 1 06 for presentation to the user using a user output device 322. The user selects which of 

the experts to use using a user input device 320. At 514, system 100 selects the expert 
prescription system based on the user's input. Thus, system 100 allows a user to select a 
custom prescription system defined for the user (if any), or to select one expert prescription 



SI 

u. 

20 system from a plurality of expert prescription systems. Central server 104 then uses the 



selected prescription system to prescribe the one or more parameters of the implantable 
medical device being programmed. 

In another embodiment, central server 104 hosts a number of expert prescription 
systems, but does not host any custom prescription systems. In this embodiment, flow chart 
25 500 is modified to eliminate 504, 506, 508 and 5 1 0. In another embodiment, central server 
104 hosts a number of custom prescription systems, but does not host any expert 
prescription systems. In this embodiment, flow chart 500 is modified to eliminate 506, 512 
and 514. 
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Referring to FIG. 6, a block diagram 600 represents one custom prescription system 

414 hosted on central server 104, according to one embodiment of system 100. Custom 

prescription system 414 is an object, including code and data, defined by a user to 

determine a set of parameters for programming an implantable medical device. The data 

5 is illustrated using a table 602 that represents a data structure that stores information 

defined by the user. The first column of table 602 identifies the type of programmable 

medical device (e.g., "Device A"). Since the first column can have multiple entries, system 

414 can be used for programming multiple types of medical devices. In another 

embodiment, system 4 1 4 is only used for programming one type of medical device, and the 

10 first column can be eliminated. 

The second colunm of table 602 identifies different classes of patients who may be 

implanted with the implantable medical device. For example, FIG. 6 indicates that two 

classes of patients (i.e.. Classes I and II) may be implanted wdth Device A. The number of 

eg classes is defined by the user, and there may be fewer than or more than two classes for 

W 

jjl 15 each device. For each class, the third column of table 602 provides a patient profile that 

fa 

defines that class. The profile of each class includes one or more attributes shared by 
M' patients in that class. For example, if a patient exhibits "Attribute 1 " and "Attribute 2", that 

P patient would be classified as being of Class I. The number of attributes that make up each 

^ patient profile is defined by the user, and each profile may include fewer than or more than 

20 two attributes. 

Each attribute is typically a fimction of one or more of the patient characteristics 
that are communicated to central server 1 04 by programmer 1 06. For example, the function 
may include a determination of whether a particular characteristic is equal to a certain value 
(e.g., is the patient female?), is within a range of values (e.g., is the most recent measured 
25 intrinsic QRS width between 80 and 1 00 msec?), is less than a value (e.g., is the QRS width 
less than 80 msec?), is greater than a value (e.g., is the QRS width greater than 100 msec?), 
etc. The fimction may also include a fimction of two or more characteristics of the patient 
(e.g., is the patient female, and is the QRS width between 80 and 100 msec?). The 
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attributes that make up a particular patient profile will be defined by the user. In one 
embodiment, programmer 106 and central server 104 cooperate to allow the user to create 
a patient profile (e.g., when the user selects this option on programmer 106), or to update 
an existing patient profile. 
5 The fourth column of table 602 specifies a set of programming parameter(s) for the 

implantable medical device 1 10 being programmed for a class of patients who exhibit the 
patient profile for that class. For example, assume that Device A has three programming 
parameters designated Parameter 1 , Parameter 2 and Parameter 3. For patients classified 
as belonging to Class I, the parameters for programming Device A are specified as 
10 Parameter 1 = Data 1, Parameter 2 = Data 2 and Parameter 3 = Data 3. For patients 
classified as belonging to Class II, the parameters for programming Device A are specified 
C as Parameter 1 = Data 4, Parameter 2 = Data 5 and Parameter 3 = Data 6. Note that data 

Q values may be the same or different for any of the parameters (e.g.. Data 1 may or may not 

S equal Data 4). 

Ijg 1 5 In one embodiment, table 602 includes a fifth column for storing a patient identifier 

^ that uniquely identifies the user's patients who belong to the particular class of patients. 

\^ For example, Andrew Adams and Bill Baxter have been classified as belonging to Class 

p I for the purposes of programming Device A, while Charlie Carlson has been classified as 

^ belonging to Class 11. Alternatively, another form of patient identifier (such as a patient 

20 identifier number) could be stored in this field. The patient identifier information may be 
used by a medical practitioner to help determine the classification of a particular patient. 
For example, a medical practitioner who is programming Device A for Doug Duncan and 
believes that Mr. Duncan's condition is similar to that of Mr. Adams may want to classify 
Mr. Duncan in the same class as Mr. Adams. In another embodiment, table 602 does 
25 include the fifth column. 

Referring to FIG. 7, a flow chart 700 illustrates logic by which system 1 00 programs 
an implantable medical device 1 10 using a custom prescription system like that of FIG. 6. 
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This logic is performed when the user has selected his or her custom prescription system 
414. 

At 702, system 100 queries the user to determine what type of medical device 110 
is being programmed. For example, in one embodiment, central server 1 04 transmits data 
5 identifying the types of medical devices specified in the first column of table 602 to 
programmer 1 06, and programmer 1 06 presents that data to the user on a user output device 
322 and receives a signal selecting one of the device types from a user input device 320. 
In another embodiment, programmer 106 determines the type of medical device being 
programmed from a signal communicated to the programmer from the medical device. In 

1 0 another embodiment, system 1 00 only programs one type of device, and 702 is not needed. 

At 704 and 706, system 100 presents patient class/patient profile information for 
the medical device being programmed to the user, and queries the user to select a patient 
class based upon which patient profile best matches the profile of the patient. For example, 
in one embodiment, the patient class/patient profile portion of table 602 is communicated 

1 5 from central server 1 04 to programmer 1 06, and programmer 1 06 presents that information 
to the user on a user output device 322 and receives a signal selecting one of the classes 
from a user input device 320. At 708, system 100 dovmloads the set of programming 
parameters for the selected patient class from central server 104 to programmer 106. At 
7 1 0, system 1 00 presents that set to the user on a user output device 322. At 7 1 2 and 7 1 4, 

20 system 1 00 queries the user to determine if these programming parameters are acceptable. 
If not, system 100 allows the user to modify one or more of the parameters at 716, and then 
returns to 712 to determine if the parameters are acceptable. Once the parameters are 
acceptable, system 100 uses progranuner 106 to program the implantable medical device 
1 10 using the parameters. 

25 At 720 and 722, system 100 queries the user to determine whether to update the 

user's custom prescription system. If not, the programming operation is complete. If so, 
system 1 00 updates the custom prescription system at 724. In one embodiment, system 1 00 
allows the user to add an identifier for the current patient to the patient identifier field of 
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the patient class that the current patient was determined as belonging to. In one 
embodiment, if any of the programming parameters was modified at 716, system 100 
allows the user to define a new patient class that corresponds to the modified set of 
programming parameters. Once the custom prescription system is updated, the 
5 programming operation is complete. 

The use of custom prescription systems may be particularly advantageous or 
convenient for medical practitioners who practice in multiple locations (e.g., at three or four 
different hospitals). By using system 100, such practitioners can store programming data 
in central server 104 where that data is always available regardless of where they are 
10 practicing. 

In one embodiment, any or all of the expert prescription systems 412 is structured 
^ similarly to custom prescription systems 414, except that the person who defines and 

□ updates the expert prescription system 4 1 2 is an expert in the field. This expert can use one 

B 

^ of expert clients 108, or can use a medical device programmer, to define or update the 

^ 15 . system 412. 

In another embodiment, any or all of expert prescription systems 412 comprises an 
\4> artificial intelligence (AI) engine. Referring to FIG. 8, a block diagram 800 represents an 

p expert prescription system 412 incorporating an AI engine, according to one embodiment 

^- of system 100. System 412 is an object, including code and data, defined by an expert to 

\^ 20 determine a set of parameters for programming a medical device. System 4 1 2 includes an 
AI engine 802, a rule database 804, a user query database 806, a patient profile database 
808, and a programming parameter set database 810. AI engine 802 is built, for example, 
using commercially-available expert-system software. Rule database 804 stores a number 
of expert system rules for use by AI engine 802. User query database 806 stores a number 
25 of user query sets. Patient profile database 808 stores a number of patient profiles, such as 
those in FIG. 6. Programming parameter set database 8 1 0 stores a number of programming 
parameter sets, such as those in FIG. 6. Expert prescription system 412 is developed by 
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having an expert work with AI engine 802 to capture the knowledge and skills of the 
expert. 

Referring to FIG. 9, a flow chart 900 illustrates logic for programming a medical 
device using the expert prescription system of FIG. 8. At 902, system 100 receives patient 
5 characteristic data from one or more sources. For example, progranmier 1 06 receives data 
from one or more of the medical device being programmed, patient monitoring system 326, 
and patient records computer system 330. At 904, system 100 selects one of the user query 
sets stored in user query database 806. Each user query set includes one or more questions 
about the patient. On the first pass through this logic, in one embodiment, the selected user 

1 0 query set is a base set of one or more questions that the expert believes is generally needed 
to determine how to program the medical device. At 906, system 1 00 presents the selected 
user query set to the user using a user output device 322. At 908, system 100 receives 
answers to the selected user query set from the user using a user input device 320. At 91 0, 
system 100 processes the answers, and the patient data from 902, using AI engine 802 to 

1 5 determine one or more possible classes of patients to which the patient might belong. 

At 912, system 100 determines whether the patient might belong to more than a 
threshold number of possible classes. The threshold represents a reasonable number of 
possible classes that could be presented to the user to select from. In one embodiment, the 
threshold number is four, although other threshold numbers such as two, three, five, etc. 

20 could be used. If there are more than the threshold number of possible classes, system 1 00 
returns to 902, so that additional data can be received from any or all of medical device 
110, patient monitoring system 326, patient records computer system 330, and the user. 
Note that the user query set selected at 904 will often contain fewer questions for the user 
at this stage, since the user has already answered some questions and system 100 is now 

25 trying to narrow the number of possible patient classifications. This iterative process 
continues until system 100 narrows the number of possible classes to less than or equal to 
the threshold number. 
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At 914, system 100 determines whether there are more than one, but no more than 
the threshold number, of possible classes to which the patient might belong. If so, at 91 6, 
system 100 presents patient class/patient profile data for all of the possible classes to the 
user to give the user the opportunity to manually select from among these classes. For 
5 example, if the threshold number is four, then the user could be presented with two, three 
or four possible patient profiles. At 91 8, system 100 determines if the user wants to select 
one of the possible classes. The user can input his or her decision using a user input device 
320. If not, system 100 returns to 902 to gather additional information in an attempt to 
further narrow the number of possible classes. If so, system 100 downloads the set of 
1 0 programming parameters for the selected class from central server 1 04 to programmer 1 06 
at 922, queries the user to determine if these parameters are acceptable at 924 and 926, and 
programs the implantable medical device using the programming parameters if acceptable 
at 928. If the parameters are not acceptable, system 100 queries the user to determine if the 



45 user wants to try another prescription system at 930 and, if so, returns to the selection logic 

I 15 (FIG. 5). 

At 9 1 4, system 1 00 determines whether there is one and only one possible class to 
M' which the patient might belong. If so, system 100 performs the programming procedure 

p of 922, 924, 926, 928, 930 described above. If, however, system 1 00 is unable to determine 

^ any possible classes to which the patient might belong, then the query "Patient 

tss? 

20 classification not available. Try again?" is presented to the user at 932, and system 100 
either allows the user to try another prescription system, or ends without programming the 
medical device. 

In the embodiment of FIG. 9, the user is not given the option of modifying the set 
of progranmiing parameters determined by the expert prescription system. This prevents 
25 the user from modifying the set in an improper manner. In another embodiment, the user 
is given the option of modifying the set of programming parameters determined by the 
expert prescription system as was discussed in relation to 716 in FIG. 7. In either case. 
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however, the user is not given the ability of modifying the prescription system defined by 
the expert. 

In one embodiment, the administrator of system 100 contracts with a number of 
experts to define the expert prescription systems, and to update the expert prescription 
5 systems at predetermined intervals. For example, a particular expert may be given an 
obligation to update the expert prescription system that she created every six months. This 
will help to insure that the expert prescription systems reflect the current state of the art. 
Client systems 108 allow the experts to update their prescription systems conveniently. In 
one embodiment, each expert prescription system includes a "valid" flag which is set to an 
10 invalid state if the expert prescription system is not updated by the expert in a timely 
fashion, and system 100 prevents the selection of any expert prescription system which is 
not valid. By enlisting experts to create and update the expert prescription systems, the 
knowledge and skills of the experts can be leveraged by being made available to any users 
of system 100. 

15 To update an expert prescription system, an expert may, for example, use the AI 

engine 802 to add a new rule to rule database 804, to delete a rule from rule database 804, 
or to modify a rule in rule database 804. For example, an expert may leam that it is 
important to determine another piece of information about a patient in order to prescribe 
a set of programming parameters, or may leam that another set of programming parameters 

20 provides improved therapy for a particular class of patient. By working with AI engine 
802, the expert can change or update the rules in rule database 804 to reflect this new 
knowledge. 

In one embodiment, central server 104 further includes a prescription verification 
system that is used to help insure that the custom and/or expert prescription systems are 
25 acceptable. In one embodiment, the prescription verification system includes a set of rules, 
or an AI system, that is used to evaluate a prescription system. For example, one of the 
rules could be that a pacemaker may not be set to operate in a monitoring mode only. 
Generally, these rules are designed to catch major problems in the definition of the 
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prescription systems that would be obviously incorrect to a person of skill in the art, rather 
than trying to catch subtle errors. In one embodiment, if the prescription verification 
system finds a violation of any of the rules, system 1 00 attempts to alert the physician (e.g., 
by automatically paging or sending an email to the physician). In another embodiment, 
system 100 does not allow the user or expert to define or update the prescription system if 
a rule violation is detected. In another embodiment, system 100 informs the user or expert 
when a rule violation is detected, and requests confirmation fi-om the user or expert before 
modifying the prescription system. 
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CoDclusion 

The above description and the accompanying drawings are intended to be 
illustrative, and not restrictive. Many other embodiments will be apparent to those of 
ordinary skill in the art upon reviewing the above description. For example, while the 
5 above description concentrates on the programming of implantable medical devices, system 
100 may be used for programming non-implantable medical devices. Also, while some of 
the functions of system 100 are described as being performed by a medical device 
programmer, the central server or an expert client, it should be understood that the 
distribution of the functions within system 100 can be modified as would be apparent to a 
1 0 person of skill in the art. Further, while this application describes particular embodiments 
of the custom prescription systems and expert prescription systems, it should be understood 
that these prescription systems can be defined in a number of different ways by the users 
and by the experts. For example, a user could also use an expert system to help define his 
^ or her custom prescription system. The scope of the present invention should therefore be 

1 5 determined with reference to the appended claims, along with the full scope of equivalents 
to which such claims are entitled. 
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